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ABSTRACT 


The  analysis  of  time-varying  images  is  curently  of  great  interest  in  computer 
vision.  There  has  been  a  deal  of  work  recently  in  the  study  of  the  2-D  image  flew 
produced  due  to  space  motion,  and  the  recovery  of  the  object’s  3-D  structure  and 
space  motion  from  the  flow.  This  report  details  the  reverse  process  implemented 
in  the  form  of  an  Image  Flow  Simulator;  from  a  knowledge  of  stucture  and  mo¬ 
tion,  to  display  the  2-D  image  sequence  and  associated  flow. This  3-D  graphics  an¬ 
imation  package  simulates  motion  of  objects  through  space  and  also  the  evolution 
of  surface  contours  through  time.  The  graphics  algorithms  for  projection,  clip¬ 
ping,  hidden  surface  removal,  shading  and  animation  are  described  in  this  report. 


The  support  of  the  Defence  Advanced  Research  Projects  Agency  and  the  U.S.  Army  Night  Vision 
Laboratory  under  Contract  DAAK70-83-K-0018  (DARPA  Order  3206)  is  gratefully  ack¬ 
nowledged. 


1.  INTRODUCTION 


This  technical  report  describes  the  Image  Flow  Simulator  (  IFS  version  1) 
developed  at  the  Computer  Vision  Laboratory  of  the  Center  for  Automation 
Research.  As  the  name  suggests,  the  package  is  a  software  tool  for  research  and 
experimentation  in  the  areas  of  time-varying  imagery,  image  flow  and  motion, 
specifically  in  the  context  of  the  overall  “Image  Flow  Paradigm”  as  described  by 
Waxman[7],  This  report  will  not  attempt  to  address  the  motivations  for  this 
approach  to  motion  analysis,  which  have  been  dealt  with  in  [7],  but  will  describe 
the  graphics  algorithms  required  in  building  the  simulator  and  examples  of  its 
use. 


The  simulator  consists  of  a  menu-driven,  three  dimensional  graphics  subsys¬ 
tem  with  certain  structural  primitives  built  in.  It  allows  the  user  to  create  a 
scene  in  3-D  space,  define  initial  positions  of  each  object  in  space,  define  observer 
motion  parameters  and  view  the  time-varying  imagery  as  the  observer  moves 
through  space.  The  simulator  also  allows  the  user  to  define  feature  points  and 
edge-contours  on  objects  in  the  scene  and  track  them  over  time.  At  each  time 
instant,  the  user  may  visualize  the  full  image  flow  produced  over  the  whole  image 
plane  of  the  observer,  or  at  specific  points  in  the  image  plane.  At  the  end  of  the 
simulation,  the  user  may  also  draw  the  image  space-time  stream  tube  associated 
with  each  image  contour[7|.  The  simulator  also  outputs  the  values  of  the  image 


flow  velocities,  and  image  plane  coordinates  of  feature  points  at  each  time 


instant;  information  that  can  later  be  utilized  for  other  experiments  such  as  those 
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those  in  Dynamic  Stereo[8|. 

The  key  ideas  in  construction  of  this  simulator  are  simplicity,  robustness  and 
modularity.  Care  has  been  taken  to  maintain  simplicity  of  algorithms  in  order  to 
keep  the  simulation  time  to  a  minimum,  since  it  is  interactive.  Robustness  is 
important  in  that  the  user  has  been  allowed  a  great  deal  of  freedom  in  setting  up 
a  scene,  with  occlusion  and  insertion  (one  primitive  partially  within  another)  pos¬ 
sible.  Being  menu  driven  in  its  present  form,  the  simulator  is  somewhat  limited, 
but  its  modular  nature  allows  new  graphical  primitives  and  algorithms  to  be 
inserted  easily.  For  example,  a  future  extension  should  allow  for  independent 
rigid  body  motions  to  be  assigned  to  each  object  in  the  scene,  as  well  as  to  the 
moving  observer. 

Section  2  describes  the  scene  and  object  primitives,  and  the  coordinate  sys¬ 
tems  used  in  the  system.  Section  3  discusses  the  various  geometric  transforma¬ 
tions  needed  for  object  display  in  static  scenes  and  for  time-varying  images.  The 
graphics  routines  for  hidden-surface  elimination  and  shading  are  discussed  in  Sec¬ 
tion  4.  Section  5  describes  the  image  flow  and  stream  tube  display  subsystems.  A 
few  sample  runs  are  included  in  the  Appendix  in  order  to  show  the  capabilities  of 
the  Image  Flow  Simulator,  as  well  as  serving  as  an  instructional  guide  to  future 
users.  The  source  code  listings,  written  in  “C”,  are  archived  on  CVL  tapes  along 
with  this  report. 


2.  COORDINATE  SYSTEMS  AND  SOLID  MODELLING 


The  observer’s  reference  frame  is  represented  by  the  right  handed  coordinate 
system  shown  in  Figure  1.  The  observer  is  located  at  the  origin,  such  that  the 
center  of  field  of  view  is  along  the  Z-axis.  The  two  dimensional  image  is  formed 
by  perspective  projection  of  points  in  the  scene  onto  a  planar  screen  oriented  nor¬ 
mal  to  the  viewing  direction,  such  that  the  image  (x,y)  origin  is  located  at 
{X,Y,Z)={0,0,f ).  This  is  similar  to  an  image  formed  in  a  pin-hole  camera  of 
focal  length  /  being  reinverted  and  reversed.  The  image  plane  size  is  variable, 

,  -imagesize  -  ,  ,  ^  imagesizt  .,  ,. 

extending  - - -  <  (  x  ,  y )  <  - - -  .  Since  the  image  coordinates 

are  scaled  by  the  focal  length  in  the  process  of  perspective  projection,  we  shall 
now  refer  to  x ,  y  as  the  scaled  directions  rather  than  image  distances.  Thus  there 
exists  a  “viewing  cone”;  images  of  objects  lying  outside  this  region  are  clipped. 

There  are  a  number  of  coordinate  systems  used  to  refer  to  the  image.  The 
system  magnifies  the  image  produced  above  into  an  internal  picture  buffer  (whose 
size  is  specified  by  the  user)  when  drawing  scenes  or  flow  vectors,  and  when  com¬ 
plete,  puts  it  in  the  display  device  window  using  device  (Grinnell)  specific  rou¬ 
tines.  The  words  “picture  buffer”  and  “work  window”  or  “device  window”  refer 
to  the  same  scene,  one  to  the  internal  workspace,  the  other  to  the  window’ 
reserved  on  the  Grinnell  for  picture  output.  Thus,  the  image  is  referenced  in  a 
variety  of  ways. 

1.  Observer’s  image  coordinates  (the  observer  screen  size  being  set  at  the  begin¬ 
ning  of  the  simulation  process), 
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2.  Picture-buffer  coordinates  (same  as  1.  except  the  image  coordinates  are 
magnified  to  the  output  picture  size  and  the  origin  is  at  the  lower  right  of 


the  picture).  This  is  related  to  the  observer  coordinates  by 


^picture-buffer  =  magnification-factor  X  x  + 


picture-size 


V picture-buffer  =  magnification-factor  X  y  + 


picture-size 


where  magnification-factor  = 


picture-size 


tmagestze 


All  calculations  of  shading,  hidden  surface  removal,  and  flow  vector  drawing 
are  done  in  this  coordinate  system. 

Picture-buffer  array  reference  values  (origin  is  at  left  top  of  picture).  This  is 
related  to  2.  by 

Xarray  =  picture— size  —  Zyidure-buffer  ~  1) 

V array  =  picture-size  -  V^Ur e-buffer  ~  1- 

Absolute  device  (Grinnell)  coordinates  (origin  is  at  left  bottom  of  picture). 
This  is  related  to  2.  by 

xgrinnell  =  picture-  8\Zt  -  X picture-buffer  ~  b 
y  grinnell  ^ picture-buffer 

The  instantaneous  rigid  body  motion  of  the  observer’s  coordinate  system  is 
specified  in  terms  of  the  translation  velocity  V  =  ( Vx ,  VY ,  Vz)  of  its  origin 
and  its  rotational  velocity  fl  =  (  fix  »  fly  ,  )■ 


2.1  SOLID  OBJECT  MODELS 


Each  object  primitive  in  the  system  has  a  lattice  of  control  points  that 
describes  its  shape  and  is  defined  in  its  own  coordinate  system.  Figure  2  shows 
these  primitive  structure  descriptions  for  each  of  the  shapes  currently  available  in 
the  system.  For  each  primitive  selected,  the  user  must  provide  characteristic 
measurements  :  the  RADIUS  of  the  sphere,  the  RADIUS  of  the  base  and  the 
HEIGHT  of  the  cone,  the  LENGTH  and  RADIUS  of  the  cylinder,  the  LENGTH, 
BREADTH,  and  HEIGHT  of  the  cuboid,  the  exents  of  the  quadratic  surface  in 
the  X-Y  plane. 

The  sphere  is  constructed  by  sweeping  the  angles  0  (longitude)  through  0  to 
360  degrees  and  <f>  (latitude)  through  -00  to  +90  degrees  at  a  constant  interval. 
The  poles  are  located  on  the  Y-axis  at  ±  RADIUS,  and  0  =  0  corresponds  to  the 
X-axis.  This  produces  an  ordering  of  the  polygons  forming  the  surface  such  that 
(at  least  for  small  angles  of  rotation  of  the  primitive)  the  visible  polygons  will  be 
drawn  first,  saving  computation  when  deciding  about  hidden  surfaces. 

The  cone  is  modelled  as  triangles,  the  tip  of  the  cone  being  fixed  at  its 
HEIGHT,  the  base  being  on  the  X-Z  plane.  The  base  is  swept  at  regular  intervals 
of  9 ,  producing  triangles  for  the  shading  algorithm. 

The  cylinder  is  formed  by  fixing  the  height  at  ±  LENGTH/2,  and  producing 
strips  along  the  sides  of  the  cylinder  by  varying  0  from  0  to  380  degrees.  Each 
strip  is  subdivided  into  two  triangles  and  shaded.  The  top  and  bottom  are  closed 
by  creating  triangles  from  the  centers  at  the  top  and  bottom  and  the  control 


points  along  the  sides. 


The  cuboid’s  sides  and  the  quadric  surface  (which  includes  a  plane)  are 
modelled  similarly,  scanning  fixed  intervals  in  two  sides  to  produce  a  grid.  Here 
again,  four  neighbouring  control  points  are  subdivided  into  triangles  and  sent  to 
the  shading  routine. 

It  must  be  noted  that  although  the  resultant  surface  is  only  a  polygonal 
approximation,  the  control  points  themselves  are  exact  points.  Also,  the  subdivi¬ 
sion  into  triangles  in  the  manner  described  above  does  not  give  rise  to  incon¬ 
sistencies  such  as  surface  patches  not  being  continuous  at  edges. 

Surfaces  are  approximated  by  polyhedra  for  reasons  of  speed.  A  best  fit  qua¬ 
dric  surface  or  spline  interpolation  was  not  used  for  describing  the  surface  since 
these  involve  much  more  computation.  The  polyhedral  approximation  leads  to 
some  errors  in  the  simulation,  but  this  is  minimized  by  other  methods  later  in  the 
process. 

.4s  can  be  seen,  it  would  not  be  difficult  to  introduce  other  primitive  shapes 
or  modify  existing  ones  (e.g.  change  the  sphere  to  a  general  ellipsoid).  There  is  a 
local  coordinate  frame  associated  with  each  primitive,  the  one  it  is  defined  in,  and 
this  is  implicitly  maintained  throughout  the  simulation  process.  Operations  such 
as  rigid  body  motions  on  an  object  are  actually  performed  by  app’ying  appropri¬ 
ate  transformation  matrices  on  the  control  points.  It  is  assumed  that  each  object 
is  a  rigid  body  in  order  to  preser  e  the  same  structural  relationship  between  the 
control  points  as  was  originally  defined,  i. e. ,  the  control  points  do  not  move  in 


0 


their  local  coordinate  system. 


Initially,  each  object’s  local  coordinate  system  is  coincident  with  the 
observer's  system.  The  user  is  then  allowed  to  place  the  objects  out  in  space  and 
thus  build  up  a  scene.  The  operator  is  given  the  option  of  seeing  the  scene  from 
the  observer’s  position,  or  from  some  other  point  in  space.  For  the  second  option, 
he  must  provide  the  new  viewing  position  and  direction.  The  coordinate 
transformation  matrices  for  these  changes  are  described  below.  Similarly,  the 
changes  in  the  scene  due  to  relative  viewer  motion  is  described  in  terms  of  a 
transformation  matrix  later. 

It  is  helpful  to  think  of  the  scene  as  a  tree  structure,  the  root  being  the 
whole  scene  itself,  and  the  branches  being  the  types  of  primitive  objects  available 
to  the  user.  Each  leaf  on  the  tree  stores  the  characteristic  measurements  of  each 
primitive.  The  system  stores  information  regarding  the  exact  position  of  each 
object  in  the  observer’s  coordinate  system  by  also  keeping  the  latest  description 
of  the  control  point  structure.  Figure  3  shows  this  hierarchical  development  of 
the  scene.  Complex  objects,  such  as  that  shown  in  Figure  4,  can  be  built  up  from 
the  structural  primitives,  although  it  does  require  a  bit  of  preplanning  to  set  each 
sub-part  in  the  correct  position,  as  there  are  so  many  parameters  to  be  set  (size, 
orientation  and  position).  It  is  important  to  note  that  our  process  of  “scene  con¬ 
struction"  does  have  an  underlying  notion  of  “attachment”  of  one  object  to 
another.  This  is  implied  by  the  sub-scene  relationships.  Unlike  SugiharaN 
approach  to  animation!')],  each  object  is  not  treated  with  independent  transfor¬ 
mation  matrices.  New  scenes,  from  different  viewing  positions  over  time,  are 
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obtained  by  applying  the  same  transformation  matrix  over  every  object  in  the 
scene.  Therefore,  relative  motion  between  objects  is  not  possible  with  the  current 
version  of  the  simulator.  It  is  one  of  the  primary  extensions  to  be  incorporated 
into  the  next  version  of  the  system. 
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3.  GEOMETRIC  TRANSFORMATIONS 


After  an  object  is  defined  in  its  own  coordinate  system,  it  is  “placed”  into 
the  world  coordinate  frame  by  multiplying  each  control  point  by  a  transforma¬ 
tion  matrix.  This  placement  is  specified  by  entering  the  rotations  of  the  object 
around  each  world  axis  (while  it  is  located  at  the  world  origin),  followed  by  its 
displacement  into  the  world.  Obviously  the  displacement  in  the  Z-direction  must 
be  greater  than  /,  since  that  is  the  focal  length  of  the  system.  Internally,  a  roia- 
tion  of  the  object  by  0  around  any  axis  is  equivalent  to  a  rotation  of  the  world 
frame  by  -0.  A  translation  of  the  object  frame  by  (  Tx,  Ty,  Tz)  is  equivalent  to 
the  world  frame  moving  (  -7\- ,  -Ty  ,  -Tz). 

Each  object  point  (  X0  ,  Y0  ,  Z0 )  is  represented  in  homogenous  coordinates  as 
(  X0  ,Y0  ,  Z0  .  1).  The  transformation  matrix  is  a  4X4  matrix  and  is  a  product  of 
standard  transformation  matrices  RX,RY,RZ  about  the  Xw  ,  Yw  ,  Zw  axes 
summed  with  a  translation  vector  (Tx ,  Ty,  Tz)  (these  can  be  found  in  [1]  or 
[3]).  The  matrix  product  is  created  internally  from  user  supplied 
9  x  ,  9y  ,9Z  ,TX ,  Ty,  Tz.  The  sequence  of  axes  around  which  rotations  occur  is 
fixed  as  given  below.  We  have 

(A-„  .  >;  .  Zw)  =  (A;  ,  Y0  .  Z0)  .  RX{-0X)  ■  Ry(-9y)  •  RA-9Z)  +  ( -Tx , -Ty , -Tz). 

On  ce  the  object  has  been  placed  in  the  world,  it  can  be  viewed  from  any 
point  in  space.  If  the  camera  is  located  at  the  origin  of  the  world  as  shown  in  Fig¬ 
ure  1.  then  the  image  coordinates  are  immediately  available  as  a  perspective 
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transform  : 


x 

7 


JL 

f 


Y,„ 


However,  if  the  operator  wishes  to  view  the  sc^ne  from  some  other  point  in  the 
world,  each  control  point  must  again  be  transformed  into  the  new  observer  coor¬ 
dinate  frame.  The  user  specifies  the  new  eye  coordinates  in  the  world 
(A',  ,  Ye  ,  Z ,)  and  the  position  of  a  point  he  is  looking  at  (Xa  ,  Ya  ,  Zj.  The 
transformation  is  set  up  as  shown: 


(Ay  ,  YJ  ,  zj  )  =  (Ay- a;  ,  >>re ,  zm-zt )  •  Rx<ej  •  r ><<?,) 


where  6X  —  arctan 


Y  -Y 

1  a  1  e 


•fiz. z  zJmx.  -  XX- 


and  O.i  =  arctan 


a>a; 


ZrZ, 


Then  a  perspective  projection  can  be  taken  in  the  new  (primed)  coordinate  sys¬ 
tem.  Note  that  one  degree  of  freedom  remains,  i.e.  rotation  around  the  new  Z 
axis  is  unfixed  and  therefore  the  images  produced  may  be  rotated  at  an  arbitrary 
angle  in  this  case. 

After  projection,  the  image  coordinates  are  magnified  into  the  picture  or 
dev  ice- window  coordinates. 
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3.1  RIGID  BODY  MOTION 

a 

IFS  creates  time-varying  images  by  assigning  a  velocity  to  the  observer  and 
tracking  each  control  point  in  the  scene  as  it  moves  relative  to  the  camera. 
Motions  of  objects  in  the  scene  are  simulated  by  assigning  the  relative  motion  to 
the  camera.  Then,  assuming  the  time  interval  between  the  frames  is  sufficiently 
short,  the  position  of  a  control  point  in  each  frame  can  be  described  in  terms  of 
the  translational  velocity  Vx ,  Vy,  Vz  and  rotational  velocity  ftx ,  fly  ,  Clz.  Both 
terms  are  assumed  to  be  small,  so  that  one  can  approximate  the  derivative  as  a 
difference.  Thus  the  displacement  due  to  the  translational  velocity  is  given  by 

S  =-Y+  Vst. 

For  infinitesimal  rotations,  we  can  represent  the  rotation  angles  as  vectors 
and  approximate 

£3  =  H  6t  , 

where  £J  =  6u>x  i  6ojy  j  +  Suz  k  . 

Infinitesimal  rotations  are  commutative,  and  therefore  interchangeable.  The 
apparent  motion  of  a  point  due  to  an  infinitesimal  rotation  of  the  camera  is  given 
by  [2] 

A*  =  R  .  X  where  R  —  1+  L 

Q  6'jJ  Z  ~6uly 

and  L  —  ~£>uz  0  6u>x  . 

6<j}y  0 

The  composite  matrix  of  both  translation  and  rotation  in  homogenous  coor¬ 


dinates  is  given  by 


(.V  ,v  ,z  n=(A-,  r,zrifo;  "  st 

\  VX  Vy  VZ  1 

During  the  simulation  of  motion  over  time,  the  observer’s  rigid  body  motion 
parameters  are  held  constant  in  his  own  evolving  reference  frame.  A  possible 
extension  for  the  future  would  be  to  incorporate  simple  dynamical  models  govern¬ 
ing  the  motion  of  objects  in  the  scene  as  well  as  motion  of  the  observer. 
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4.  GRAPHICS  ROUTINES 

• 

There  are  two  major  components  of  the  graphics  routines:  removal  of  hidden 
surfaces  and  quasi-realistic  shading.  The  input  to  these  two  routines  is  a  polygon 
formed  by  three  points  in  the  world  coordinate  system  as  described  in  Section 
2.1.  The  problem  of  removal  of  occluded  surfaces  has  been  solved  in  many 
elegant  algorithms,  most  involving  some  kind  of  sorting  of  the  polygons  forming 
an  object  [6],  These  algorithms  were  not  used  since  time  varying  images  change 
the  ordering  of  the  polygons.  This  would  require  the  data  structure  to  be  sorted 
at  each  frame,  a  time-consuming  process.  The  following  table  from  [1]  shows  the 
relative  effectiveness  of  four  hidden-surface  removal  algorithms. 


Algorithm 

Number  of  Poh 

rgonal  faces 

100 

2500 

60000 

Depth  sort 

1* 

10 

507 

Z-Buffer  (IFS) 

54 

54 

54 

Scanline 

5 

21 

100 

Warnock  Area  Subdivision 

11 

64 

307 

♦Values  scaled  so  that  this  is  1. 


The  most  effective  algorithm  for  our  purposes  was  found  to  be  the  “Z-Buffer” 
method,  since  a  typical  scene  in  IFS  has  about  3000  polygons.  This  method  is  an 
extremely  simple  one,  that  of  keeping  a  two-dimensional  array  whose  content  is 
the  Z-distance  associated  with  each  pixel  of  the  picture.  A  point  in  space  is  visi¬ 
ble  if,  after  perspective  transformation,  the  Z-distance  associated  with  the  image 
pixel  is  less  than  the  contents  of  the  corresponding  location  in  the  Z-buffer.  This 
requires  keeping  a  floating  point  array  the  size  of  the  output  picture;  for  a 
256X256  picture  memory  on  the  order  of  1MB  is  required.  However,  it  turns  out 
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to  be  useful  to  keep  a  Z-depth  map  for  the  later  calculations  involving  image 
flow.  Also,  depth-sort  methods  generally  do  not  allow  for  penetrating  polygons,  a 
necessary  feature  in  EFS.  .Algorithms  utilizing  frame-to-frame  coherence  of 
images  such  as  [4]  are  available,  but  are  not  robust  enough  for  our  requirements, 
allowing  only  camera  motion,  and  thus  incompatible  with  planned  extensions  of 
the  simulator. 

Shading  and  depth  mapping  are  done  simultaneously  in  picture  coordinates 
(in  scan-line  order)  by  first  interpolating  between  the  control  point  image  pixels 
to  the  current  scan  line,  and  then  interpolating  between  the  two  boundary  values 
(determined  by  the  triangle  and  the  scan  line)  to  set  the  shade  and  Z  value  for 
individual  pixels.  The  regions  of  the  image  outside  the  picture  frame  are 
“clipped”  against  the  edges  of  the  device  window  at  the  same  time  that  the 
polygons  are  shaded. 

Each  control  point  of  a  polygon  in  world-coordinates  is  transformed  into 
image  coordinates  (floating  point)  and  then  expanded  and  rounded  into  the  dev¬ 
ice  frame  pixels  (integer).  Initially,  the  Z-distance  associated  with  this  pixel  in  the 
Z-BufTer  was  taken  to  be  that  of  the  associated  control  point;  however,  this  leads 
to  errors  due  to  roundoff.  In  order  to  find  the  correct  value  of  Z  corresponding  to 
this  pixel,  a  ray  emanating  from  the  origin  of  the  world  coordinate  system  and 
passing  through  the  pixel’s  image  coordinate  is  backprojected  onto  the  plane 
formed  by  its  three  associated  control  points.  The  Z  value  is  found  from  the  point 
of  intersection  of  the  ray  and  the  plane,  the  equation  being  solved  by  Cramer's 
rule.  The  solution  is  unstable  for  a  plane  that  is  nearly  tangential  to  the  ray;  this 
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condition  is  dealt  with  as  a  special  case.  The  backprojection  procedure  is  repeated 
for  each  of  the  three  control  points,  and  the  Z-map  built  up  by  lifiear  interpola¬ 
tion  when  the  scene  is  shaded. 

Shading  models  attempt  to  recreate  the  effects  of  lighting  in  the  scene.  The 
simplest  is  to  model  the  surfaces  as  exhibiting  diffuse  reflection  (such  that  it 
appears  to  have  the  same  brightness  from  any  viewing  position)  and  the  light 
source  as  a  plane  with  rays  parallel  to  the  Z-axis.  The  intensity  of  light  calculated 
by  Lambert’s  cosine  law  is 

I  —  k  L  •  N  where  ZT  is  the  direction  of  the  light  source, 

k  is  the  diffuse  reflection  coefficient, 
and  N  is  the  surface  normal. 

fFS  models  the  light  source  as  a  point  source  and  allows  the  operator  to 
position  it  anywhere  in  the  world.  A  point  source  of  light  yields  spherical  light 
waves  impinging  on  the  scene;  however,  we  do  not  take  into  account  the  inverse- 
square  degradation  of  intensity  with  distance.  Such  lighting  allows  for  more  real¬ 
istic  shading  of  planar  surfaces  in  space.  For  each  polygon,  we  find  the  surface 
normal  by  taking  the  cross  product  of  the  vectors  along  two  sides,  and  calculate 
the  intensity  as  the  inner  product  as  shown  above.  The  coefficient  k  is  chosen  to 
be  1,  and  the  value  scaled  such  that  7=1  corresponds  to  white  (gray  level  255) 
and  7=0  to  black  (gray  level  0).  In  this  manner  we  find  the  intensity  of  each 
polygon.  Note  that  for  diffuse  reflection,  the  intensity  depends  only  upon  the 
angle  between  the  surface  normal  and  the  light  source,  not  on  viewing  direction. 
The  simulator  does  not  at  present  allow  for  specular  reflection  or  shadowing 


effects.  More  complex  algorithms  for  shading  can  be  found  in  [1]. 

The  fact  that  one  finds  the  angle  between  the  surface  normal  and  the  light 
source  is  also  used  to  speed  up  the  process  of  hidden  surface  elimination.  If  the 
light  source  is  placed  at  the  origin,  then  for  closed  convex  polyhedra  (all  the 
primitive  objects  except  the  quadric  surface)  a  polygon  is  visible  only  if  this  angle 
is  between  ±90".  If  the  angle  is  greater  than  these  values,  then  the  surface  is 
obviously  facing  away  from  the  light  source,  and  hence  the  camera  origin,  and 
therefore  is  not  processed  further.  This  method  can  only  be  used  if  the  source  is 
positioned  at  the  origin. 


5.  FEATURE  POINTS,  CONTOURS  AND  IMAGE  FLOW 


Feature  points  and  contours  can  be  defined  on  the  objects  in  the  scene  and 
displayed  as  the  scene  changes  over  time.  They  have  been  included  in  order  to 
allow  visualization  of  image  contour  deformation  and  neighborhood  evolution 
(Figs.  5,6).  A  contour  is  approximated  as  straight  line  segments  between  vertices, 
stored  in  an  appropriate  data  structure.  Therefore,  both  individual  feature  points 
and  curve  vertices  can  be  stored  in  the  same  structure.  Currently,  IFS  handles 
three  ways  of  defining  the  feature  points  and  contours: 

1.  Interactively  using  the  trackball  and  Grinnell-specific  routines.  The  cursor  is 
located  at  the  desired  position  of  the  feature  (or  vertex),  and  the  point  is 
entered.  IFS  finds  the  relative  location  of  the  point  in  the  device  window 
coordinates,  and  converts  from  this  to  the  image  plane  and  to  the  world 
coordinate  system  by  once  again  finding  the  range  in  the  Z-buffer  and  revers¬ 
ing  the  perspective  transform.  The  user  is  given  the  safeguard  of  trashing 
the  value  in  order  to  recover  from  mistakes. 

2.  From  a  file  (in  predetermined  format)  containing  the  image  coordinates  and 
other  data  regarding  the  feature  (being  individual  feature  points  or  a  curve) 
and  the  number  of  points  (vertices  for  contours)  in  the  feature.  The  actual 
world  coordinates  corresponding  to  these  image  coordinates  is  calculated  by 
extracting  the  Z-distance  from  the  Z-buffer,  and  then  reversing  the  perspec¬ 
tive  transform.  The  format  for  this  file  is  given  below: 


ir 


<0/l> 

<xl> 

<x2> 

<n> 

<yi> 

<y2> 

/♦Feature  type  and  number  of  feature  points/vertices 
/*0=lndividual  feature  points,  l=feature  curve 
/* 

/*x,y  coordinates  of  features  in  image  coordinates 

A* 

a 

x  o 
.  V  V 

<yn> 

<nl> 

/♦repeat  for  next  feature 

3.  From  a  file  containing  the  world  coordinates  of  the  features  (this  file  is 
written  in  binary)  which  is  created  by  IFS  on  demand  for  experiments  such 
as  those  desired  for  studying  base-line  effects  on  Dynamic  Stereo. 

The  world  coordinates  of  a  feature  point  are  used  in  order  to  find  the  loca¬ 
tion  of  the  feature  point  at  different  time  steps.  The  transformation  matrices  used 
are  the  ones  described  in  Section  3.  There  is  one  difference  between  the  treatment 
of  a  feature  and  that  of  an  object  control  point;  the  feature  point  is  “painted”  on 
the  surface  in  the  scene  by  projecting  the  image  coordinates  of  the  features  into 
the  world  and  then  joining  them  by  straight  line  segments.  These  segments  are 
not  compared  against  the  Z-buffer  to  find  occlusion,  since  joining  feature  points 
across  polygon  boundaries  would  cause  the  segments  to  be  occluded.  However, 
the  present  method  also  has  drawbacks  in  cases  where  a  genuine  occlusion  (due  to 
observer  motion,  perhaps)  is  not  displayed.  This  problem  could  be  rectified  by 
setting  a  distance  threshold  for  occlusion  of  contours. 

When  defining  the  contours  and  feature  points  interactively  through  the 
trackball,  the  trackball  must  be  set  to  “cursor#l”  (the  program  is  only  set  up  to 
read  this  cursor)  and  must  be  set  in  “point”  mode(not  “track”).  The  color  of  the 
cursor  (black  or  white)  can  be  changed  from  the  trackball  depending  upon  the 
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background. 


The  current  version  of  the  simulator  only  allows  for  features  and  contours  to 
be  placed  on  the  initially  visible  portions  of  the  object  surfaces.  Future  extension 
will  allow  for  all  sides  of  objects  to  be  “decorated”  before  they  are  moved  out 
into  the  scene. 

5.1  IMAGE  FLOW 

As  a  rigid  object  or  the  monocular  observer  moves  through  space,  an  image 
sequence  or  flow  field  is  created  on  the  observer’s  focal  plane.  This  flow  is  deter¬ 
mined  by  the  parameters  of  space  motion  and  the  structure  of  objects  in  the 
scene.  The  flow  is  mathematically  defined  as  the  time  derivative  of  the  image 
coordinates  of  a  feature  due  to  the  motion  of  the  corresponding  point  in  3D 
space.  The  flow  equations  are  taken  from  Waxman  and  Ullman  [9].  At  each  time 
step  of  the  simulation  process,  the  user  may  find  the  full  image  flow  vectors 
either  at  the  specified  feature  points  on  the  surface  or  on  a  grid  over  the  whole 
image.  Since  both  the  relative  motion  parameters  of  the  observer  and  the  param¬ 
eters  of  the  objects  in  the  scene  are  known,  computation  of  the  flow  is  straight¬ 
forward;  it  is  given  by  the  set  of  equations 

v,  ={  x - -y  }  +  l  i  y  (  1  +  r  )  ny  +  yQz] 

v,  =  {y-“--^|  +  K1  +  »2)nAr-xyny-  xQz] 

Although  the  system  allows  the  focal  length  and  image  size  to  be  variable,  these 


values  must  be  set  to  1  for  image  flow  calculations.  As  expected,  the  flow  values 
obtained  through  the  simulator  are  not  exact  due  to  the  interpolated  Z-buffer, 
but  have  been  found  to  be  adequate  for  experiments  carried  out  in  [8].  For  a 
plane,  the  error  has  been  found  to  be  on  the  order  of  0.1  percent. 

The  positions  where  the  flow  is  calculated  are  found  in  picture  coordinates 
(integer),  so  that  one  can  also  access  the  range  value  using  the  same  coordinates 
in  the  Z-buffer.  The  Z-buffer  is  sampled  at  intervals  of  some  user-specified  size  if 
the  user  wishes  to  display  the  flow  field  as  a  grid  over  the  image  (option  1),  or  is 
found  at  the  image  coordinates  corresponding  to  the  features  defined  earlier 
(option  2).  These  integer  coordinates  are  later  converted  into  the  x,y  coordinates 
of  the  image  plane.  All  quantities  in  the  above  equations  are  specified,  and  the 
full  flow  can  easily  be  constructed.  Examples  are  shown  in  Figure  6. 

The  flow  field  is  displayed  as  vectors  at  the  points  where  it  is  calculated,  the 
vector  length  being  scaled  to  either  the  grid  spacing  in  option  1  or  to  some  user 
specified  length  in  option  2.  Bresham’s  algorithm  is  used  for  line  drawing  since  it 
is  a  highly  efficient  line  drawing  routine  involving  fewer  floating  point  operations 
than  the  usual  y=mx-l-c  approach  [l].  However,  no  attempt  is  made  at  antialias¬ 
ing  the  line  to  remove  j aggies.  Both  the  drawing  of  the  small  curve  segments  and 
the  flow  vectors  use  the  same  algorithm.  The  final  clipping  of  lines  against  the 
device  window  edges  occurs  as  in  the  shading  process. 

The  flow  values  and  the  corresponding  image  coordinates  at  which  they  are 
calculated  are  then  stored  in  a  specified  file  for  later  use.  In  its  current  version, 
the  simulator  does  not  put  flow  values  of  different  features  into  separate  files,  and 
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only  finds  the  full  flow  (as  opposed  to  the  normal  flow)  at  vertices  of  the  feature 
contour. 

5.2  STREAM  TUBES 

At  the  end  of  the  simulation  process,  IFS  allows  the  user  to  create  the 
stream  tubes  corresponding  to  the  evolving  contours  [7).  The  stream  tube  is  an 
image  space-time  representation  of  the  deformation  of  a  contour  in  an  image  (see 
Fig.  5).  It  is  a  three  dimensional  representation,  two  axes  representing  the  x,y  of 
the  image  plane,  while  the  third  axis  represents  time.  The  stream  tube  is  drawn 
individually  for  each  of  the  contours  in  the  scene.  The  image  of  the  curve  in  the 
world  coordinates  is  found  by  perspective  projection  and  once  again  placed  in 
front  of  the  eye  through  a  transformation  matrix  given  by 

cos(45°)  sin(45*)  0  0 

-sin(45<’)  cos(45#)  0  0 

0  0  10 
0  stackspace  50  0 

This  is  done  for  the  image  of  each  of  the  contours  at  each  time  instant  and  the 
images  separated  along  the  f-axis  by  the  “stackspace”.  This  quantity  is  a  user 
specified  value  representing  the  distance  in  graphic  units  between  the  images  at 
each  time  step.  The  curve  x,y  coordinates  in  the  image  at  each  time  instant  are 
automatically  stored  in  a  specified  file.  The  option  of  drawing  a  stream  tube 
should  only  be  used  for  feature  contours  in  the  image  plane,  not  for  feature 
points.  As  a  last  option  in  the  simulator,  IFS  also  allows  the  user  to  visualize  the 
motion  of  each  of  the  vertex  points  of  the  contour  over  time,  i.e.,  each  contour 
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vertex  is  connected  by  straight  line  segments  to  its  image  in  the  next  time  frame. 


It  must  be  noted  that  the  system  assumes  that  the  stream  tube  is  being 
drawn  for  the  feature  contours  only,  not  for  the  feature  points.  If  it  is  given  a  set 
of  feature  points  to  draw  a  stream  tube  of,  it  may  attempt  to  join  up  the  points 
in  an  arbitrary  fashion.  However,  the  final  option,  to  join  feature  points/contour 
vertices  over  time,  may  be  used  in  either  case. 


22 


0.  PORTABILITY  AND  EXTENSIONS 


The  current  version  of  the  Image  Flow  Simulator  has  been  written  in  “C” 
for  the  Computer  Vision  Laboratory’s  VAX  11/780  running  Unix  4.1BSD.  It  uses 
a  number  of  site  specific  routines,  but  these  are  isolated  in  a  few  subroutines  that 
are  mentioned  in  the  listing  of  the  package.  They  are  related  to  the  available 
Grinnell  graphics  system,  and  to  the  configuration  at  the  CVL.  The  package  of 
routines  available  in  the  library  “-lgr”  is  used  to  initialize  the  work  window  on 
the  Grinnell;  to  put  the  internal  work  buffer  onto  the  display;  to  control  the  cur¬ 
sor  and  trackball  while  defining  features;  and  to  draw  line  segments  while  creat¬ 
ing  the  feature  contours.  These  are  the  only  routines  which  would  need  to  be 
replaced  at  other  installations  running  a  UNIX/C  environment. 

0.1  EXTENSIONS 

1.  The  simulator  should  be  converted  into  a  graphics  language,  allowing  the  user 
to  create  his  own  simulation  stream,  thus  removing  the  drawback  of  being  menu 
driven.  This  would  require  only  minor  modifications  due  to  the  modular  nature  of 
the  current  version.  The  graphics  core  is  already  present  in  the  current  version;  a 
language  would  merely  require  an  interpreter. 

2.  IFS  should  allow  for  independent  rigid  body  motions  of  each  object  in  the 
scene,  rather  than  restricting  motion  to  only  the  camera  as  is  currently  the  case. 
This  would  require  a  slight  modification  in  the  data  stucture  representing  the 
scene  so  that  a  transformation  matrix  can  be  associated  with  each  object  in  the 
scene.  This  would  make  the  IFS  similar  to  the  graphics  animation  system  of 
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Sugihara  [5]. 

3.  It  should  be  possible  to  “paint”  features  on  all  faces  of  objects  at  the  start  of 
simulation,  not  merely  on  the  visible  areas.  The  features  should  have  a  range 
explicitly  stored  with  the  control  points  in  the  data  structure,  and  their  occlusion 
should  also  be  calculated  and  displayed. 
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7.  CONCLUSIONS 


This  report  has  described  the  first  version  of  the  Image  Flow  Simulator 
currently  in  use  by  the  motion  research  group  at  the  Computer  Vision  Labora¬ 
tory.  It  allows  the  user  to  quickly  visualize  the  effects  of  observer  motion  with 
respect  to  a  static  scene,  and  the  evolution  of  feature  points  and  contours  in  that 
scene.  This  should  be  of  help  in  understanding  the  concepts  of  neighborhood 
deformation,  contour  evolution,  image  flow  and  other  ideas  associated  with  time- 
varying  imagery.  We  expect  that  the  simulator  will  prove  to  be  a  useful  tool  in 
motion  studies. 

We  wish  to  acknowledge  the  resources  provided  at  the  Computer  Vision 
Laboratory  of  the  Center  for  Automation  Research  in  the  development  of  the 


simulator. 


APPENDIX 


The  Command  sequence  for  executing  the  Image  Flow  Simulator  program  is: 

IFS  internalbuffer  flowvalues  features 

The  three  files  required  in  the  command  line  are: 

internalbuffer  -  a  file  for  working  on  the  picture  buffer  internally. 

flowvalues  -  contains  the  image  flow  values  calculated  and  the  image 
coordinates  at  each  of  the  points. 

features  -  contains  the  coordinates  of  the  feature  points/ vertices  of  the 
contours  initially.  If  the  feature  is  not  to  be  defined 
through  a  file,  then  a  dummy  file  name  must  be  used.  At  the 
end  of  a  simulation  run  this  file  contains  the  image 
coordinates  of  the  points  at  each  time  instant.  The  initial 
contents  of  this  file  are  destroyed. 

A  sample  run  is  shown  below.  User  responses  are  indicated  in  italics. 

*:M*************************************************************************** 

Image  Flow  Simulator  [version  1] 

Do  you  need  help?  yea 


This  program  allows  you  to  create  time  varying  images 
of  objects  in  3-d  space.  You  must  specify  tht  objects 
in  the  scene  and  their  parameters,  and  the  viewer 
motion  parameters.  Perspective  projection  is  used  to 
create  the  image,  so  an  object  of  size  10  units  at  a 
distance  of  100  from  the  observer  will  produce  the  same 
image  as  one  of  size  1  at  a  distance  of  10  units 
...More...?  yes 

Imagine  that  the  screen  is  +/-  0.5  units  in  x  and  y, 
and  at  a  distance  of  1  unit  from  you  in  Z  (this  image  is 
then  expanded  to  the  Grinnell  screen  size.)  Thus  the  angle 
of  viewing  is  about  -f~ 30  degrees.  The  coordinate  system 
shown  above  always  moves  with  the  observer,  so  that  you  will 
always  be  looking  down  the  z-axis.  Note  that  due  to  relative 
motion,  if  you  specify  a  positive  velocity  in  x,  the  image 
will  move  to  the  right(in  the  negative  x  direction). 


Enter  Grinnell  window  size(  integer )‘200 


Enter  the  coordinates  of  the  lower  left  hand  corner 
of  the  Grinnell  window  to  be  used 
column  value  =  0 
row  value  =  0 


Enter  focal  length  of  camera  unit(commonly  1)  :  1 


Enter  image  plane  size(commonly  1)  :  1 
Options: 

0:  Fast  algorithm,  light  source  fixed  at  origin. 

1:  Light  source  position  variable 
Choice  :  1 

Specify  position  of  point  light  source. 

X  coordinate  of  light  source  =50 
V  coordinate  of  light  source  =50 
Z  coordinate  of  light  source  =0 

Menu  : 

Choose  objects  in  scene(upto  5  of  any  one  type) 
0  — >  to  terminate  object  creation  loop 

1  — >  Cone 

2  — >  Cylinder 

3 — >  Parallelepiped 

4  — >  Sphere 

5  — >  Surface 

6  — >  Help  function 
Choice  of  object  number  :1 

Cone  origin  is  at  center  of  base 
Height  of  cone  =  20 
Radius  of  cone  =  10 
Euler  angle  of  cone  (in  integer  degrees). 
Rotation  about  x(horizontal)  axis  =  0 
y(vertical)  axis  =  0 
Rotation  about  z(horizontal)  axis  =  0 
Where  would  you  like  to  place  the  cone? 
enter  the  x-coordinates  of  the  cone  origin  -5 
enter  the  v-coordinates  of  the  cone  origin  25 
enter  the  z-coordinates  of  the  cone  origin  110 


You  have  the  option  of  seeing  the  scene  from  the 
observer’s  point  of  view  or  from  another  point  in  space. 

Will  you  see  observer’s  view?  Your  reply  must  be  either  yes  or  no. 
yea 

cone  drawn 

_ see  fig  6  a 

Delete  object  from  scene? 
no 

Want  to  change  light  source  position  for  next  display? no 

Choose  objects  in  scene(upto  5  of  any  one  type) 

0  — >  to  terminate  object  creation  loop 

1  — >  Cone 

2  — >  Cylinder 

3  — >  Parallelepiped 

4  — >  Sphere 

5  — >  Surface 

6  — >  Help  function 
Choice  of  object  number  :2 

Cylinder  is  drawn  from  +length/2  to  -hngth/2 

Length  of  cylinder  —  30 

Radius  of  cylinder  =  10 

Euler  angle  of  cylinder  (in  integer  degrees). 

Rotation  about  x(horizontal)  axis  =  0 
y(vertical)  axis  =  0 
Rotation  about  z(horizontal)  axis  =  0 
Where  would  you  like  to  place  the  cylinder? 
enter  the  x-coordinates  of  the  cylinder  origin  -5 
enter  the  y-coordinates  of  the  cylinder  origin  10 
enter  the  z-coordinates  of  the  cylinder  origin  110 

You  have  the  option  of  seeing  the  scene  from  the 

observer's  point  of  view  or  from  another  point  in  space 

Will  you  see  observer’s  view?  Your  reply  must  be  either  yes  or  no. 

yes 

cylinder  drawn 

_ see  fig  6  b 

Delete  object  from  scene? 
no 

Want  to  change  light  source  position  for  next  display?no 

Choose  objects  in  scene(upto  5  of  any  one  type) 

0  — >  to  terminate  object  creation  loop 
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1  — >  Cone 

2  — >  Cylinder 

3 — >  Parallelepiped 

4  — >  Sphere 

5  — >  Surface 

6  — >  Help  function 
Choice  of  object  number  :3 

Parallelepiped  is  located  (0,0,0), (length, 0,0) 

(0,0,breadth),(0,height,0) . 

Length  of  parallelepiped(in  x)  =20 

Breadth  of  parallelepiped(in  z)  =20 

Height  of  parallelepiped(in  y)  =20 
Euler  angle  of  cube  (in  integer  degrees). 
Rotation  about  x(horizontal)  axis  =  -10 
y(vertical)  axis  =  25 
Rotation  about  z(horizontal)  axis  =  0 
Where  would  you  like  to  place  the  cube? 
enter  the  x-coordinates  of  the  cube  origin  -15 
enter  the  y-coordinates  of  the  cube  origin  -15 
enter  the  z-coordinates  of  the  cube  origin  65 


You  have  the  option  of  seeing  the  scene  from  the 
observer’s  point  of  view  or  from  another  point  in  space 
Will  you  see  observer’s  view?  Your  reply  must  be  either  yes 
no 

Specify  new  viewing  position: 
x  value  in  old  coordinate  system  =  50 
y  value  in  old  coordinate  system  =  20 
z  value  in  old  coordinate  system  =  10 

Specify  viewing  direction  by  providing  coordinates  of 
some  point  you  are  looking  at. 

x  value  of  this  new  point  in  old  coordinate  system  0 

y  value  of  this  new  point  in  old  coordinate  system  0 

z  value  of  this  new  point  in  old  coordinate  system75 

cone  drawn 
cylinder  drawn 

rectangular  parallelepiped  drawn 


Delete  object  from  scene? 

Your  reply  must  be  either  yes  or  no. 
no 

Want  to  change  light  source  position  for  next  displayTno 

Choose  objects  in  scene(upto  5  of  any  one  type) 

0  --->  to  terminate  object  creation  loop 

1  — >  Cone 

2  — >  Cylinder 

3  — >  Parallelepiped 

4  — >  Sphere 

5  — >  Surface 

6  — >  Help  function 
Choice  of  object  number  :4 

Center  of  sphere  is  at  origin 

Radius  of  sphere  =  15 

Euler  angle  of  sphere  (in  integer  degrees). 

Rotation  about  x(horizontal)  axis  =  0 
y(vertical)  axis  =  0 
Rotation  about  z(horizontal)  axis  =  0 
Where  would  you  like  to  place  the  sphere? 
enter  the  x-coordinates  of  the  sphere  origin  5 
enter  the  y-coordinates  of  the  sphere  origin  -10 
enter  the  z-coordinates  of  the  sphere  origin  85 

You  have  the  option  of  seeing  the  scene  from  the 

observer’s  point  of  view  or  from  another  point  in  space 

Will  you  see  observer’s  view?  Your  reply  must  be  either  yes  or  no. 

yes 

cone  drawn 
cylinder  drawn 

rectangular  parallelepiped  drawn 
sphere  drawn 

_ see  fig  6  d 

Delete  object  from  scene? 
no 

Want  to  change  light  source  position  for  next  display?yes 

Specify  position  of  point  light  source. 

X  coordinate  of  light  source  =0 
Y  coordinate  of  light  source  =0 
Z  coordinate  of  light  source  =0 


Choose  objects  m  scene(upto  5  of  any  one  type) 

0  — >  to  terminate  object  creation  loop 

1  — >  Cone 

2  — >  Cylinder 

3  — >  Parallelepiped 

4  — >  Sphere 

5  —  >  Surface 

6  — >  Help  function 
Choice  of  object  number  :5 
Bounding  limits  of  surface(max+/-49): 
minimum  X:  -30 

maximum  X:  30 
minimum  Y:  -30 
maximum  Y:  30 

Enter  the  coefficients  of  the  2nd  order  surface 
in  the  order  Z  =  aX‘2+bXY+cY*2+dX+eY+f 
a  =  0 
b  =  0 
c  =  0 
d  =  0 
e  =  2 
f  =  100 

You  have  the  option  of  seeing  the  scene  from  the 

observer’s  point  of  view  or  from  another  point  in  space 

Will  you  see  observer’s  view?  Your  reply  must  be  either  yes  or  no. 

yes 

cone  drawn 
cylinder  drawn 

rectangular  parallelepiped  drawn 
sphere  drawn 
surface  drawn 

Delete  object  from  scene? no 

Want  to  change  light  source  position  for  next  display? no 


stt  fig  6  t 


Choose  objects  in  scene(upto  5  of  any  one  type) 
0  — >  to  terminate  object  creation  loop 

1  --->  Cone 

2  — >  Cylinder 

3— ->  Parallelepiped 

4  —  >  Sphere 

5  — >  Surface 

6  — >  Help  function 
Choice  of  object  number  :0 
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Would  you  like  to  define  feature  points  on  the  image? 

Your  reply  must  be  either  yes  or  no. 
yea 

Options: 

0:  You  can  define  features  interactively  using  the  trackball 
1:  You  can  define  features  by  reading  image  coordinates  from  a  file 
2:  You  can  use  the  feature  points  saved  from  options  1  or  2  in  a 
previous  simulation  run 
Choice?l 

Want  to  define  other  curves(using  trackball)?  Your  reply  must  be  either  yes  or  no 
Do  you  wish  to  save  the  feature  point  coordinates  for  later  use?  no 

Specify  the  viewer  motion  parameters. 

Translational  velocities  in  units/time  step 
Vx  =  1 
Vy  =  2 
Vz  =  10 

Rotational  velocities  in  radians/time  step 
Ox  =  0.08 
Oy  =  0.09 
Oz  =  0.1 

Specify  number  of  time  instants  after  which  view  is  required  :  1 

Would  you  like  to  see  the  scene  at  time  0  on  the  Grinnell? 

Your  reply  must  be  either  yes  or  no. 
yea 

cone  drawn 
cylinder  drawn 

rectangular  parallelepiped  drawn 

sphere  drawn 

surface  drawn 

feature  points  drawn 

Save  the  scene? 

yes 

Enter  the  filename  in  which  to  save  :  scene.  1 

_ aee  fig  6  f 

Would  you  like  to  see  the  flow  at  time  0  on  the  Grinnell? 

Your  reply  must  be  either  yes  or  no. 
yes 

Options: 

0  :  You  can  find  the  flow  at  the  (individual)  feature  points. 

1  ;  You  can  find  the  flow  on  a  grid  over  the  whole  image. 

Choice?  0 
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Interval  for  plotting  flow  vectors  (in  pixeis)=  20 
Save  the  scene? 

Your  reply  must  be  either  yes  or  no. 
yes 

Enter  the  filename  in  which  to  save  :  flow.l 

_ set  fig  6  g 

cone  drawn 
cylinder  drawn 

rectangular  parallelepiped  drawn 

sphere  drawn 

surface  drawn 

feature  points  drawn 

Save  final  scene? 

Your  reply  must  be  either  yes  or  no. 
yes 

Enter  the  filename  in  which  to  save  :  scene. 2 

_ see  fig  6  h 


Would  you  like  to  see  the  stream  tube? 

Your  reply  must  be  either  yes  or  no. 
no 

******************************************************************** 
The  user  specifies  the  maximum  number  of  time  instants  of  the  simulation  run 
(in  the  above  example,  this  has  been  set  to  1) 

and  the  simulator  executes  from  t  =  0  till  this  time  step.  The  final  scene 
is  always  drawn  (see  Fig.  6h).  The  simulator  then  draws  the  stream  tube  if 
necessary  and  also  displays  the  motion  of  each  individual  point  through 
image  space-time. 
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Figure  4.  Example  of  complex  object 
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Figure  5.  Contour  evolution  and  the  stream  tube 


Figure  6.  Typical  scene  being  set  up 


Figure  7.  a)  Cylinder  . 

b)  Flow  grid.  Space  motion  is  translational  only. 

c)  Cube  with  contour. 

d)  Flow  at  contour  vertices.  Space  motion  is  rotational  and  translational. 
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